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1  Introduction 


Due  to  the  exponential  increase  of  offered  services  in  the  most  famous  offspring 
of  the  Internet,  the  World  Wide  Web,  searching  and  selecting  relevant  services  is 
essential  for  users.  Various  search  engines  and  software  agents  providing  various 
different  services  are  already  deployed  on  the  Web.  However,  novice  users  of 
the  Web  may  have  no  idea  where  to  start  their  search,  where  to  find  what  they 
really  want,  and  what  agents  are  available  for  doing  their  job.  Even  experienced 
users  may  not  be  aware  of  every  change  in  the  Web,  e.g.,  relevant  web  pages 
might  not  exist  or  their  content  be  valid  anymore,  and  agents  may  appear  and 
disappear  over  time.  The  user  is  simply  overtaxed  by  manually  searching  in  the 
Web  for  information  or  appropriate  agents. 

On  the  other  hand,  as  the  number  and  sophistication  of  agents  on  the  Web 
that  may  have  been  developed  by  different  designers  increases,  there  is  an  obvi¬ 
ous  need  for  a  standardized,  meaningful  communication  among  agents  to  enable 
them  to  perform  collaborative  task  execution.  We  distinguish  two  general  agent 
categories,  service  providers  and  service  requester  agents.  Service  providers 
provide  some  type  of  service,  such  as  Ending  information,  or  performing  some 
particular  domain  specific  problem  solving  (e.g.  number  sorting).  Requester 
agents  need  provider  agents  to  perform  some  service  for  them.  Since  the  In¬ 
ternet  is  an  open  environment,  where  information  sources,  communication  links 
and  agents  themselves  may  appear  and  disappear  unpredictably,  there  is  a  need 
for  some  means  to  help  requester  agents  find  providers.  Agents  that  help  locate 
others  are  called  middle  agents. 

We  have  identified  different  types  of  middle  agents  in  the  Internet,  such 
as  matchmakers  (yellow  page  services),  brokers,  billboards,  etc.  [3],  and  ex¬ 
perimentally  evaluated  different  protocols  for  interoperation  between  providers, 
requesters  and  various  types  of  middle  agents.  Figure  1  shows  the  protocol  for 
two  different  types  of  middle  agents:  brokers  and  matchmakers.  We  have  also 
developed  protocols  for  distributed  matchmaking  [12].  The  process  of  finding 
an  appropriate  provider  through  a  middle  agent  is  called  matchmaking.  It  has 
the  following  general  form: 

•  Provider  agents  advertise  their  capabilities  such  as  know-how,  expertise, 
and  so  on,  to  middle  agents. 

•  Middle  agents  store  these  advertisements. 

•  A  requester  asks  some  middle  agent  whether  it  knows  of  providers  with 
desired  capabilities. 

•  The  middle  agent  matches  the  request  against  the  stored  advertisements 
and  returns  the  result. 

While  this  process  at  first  glance  seems  very  simple,  it  is  complicated  by  the 
fact  that  providers  and  requesters  are  usually  heterogeneous  and  incapable  in 
general  of  understanding  each  other.  This  difficulty  gives  rise  to  the  need  for  a 
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common  language  for  describing  the  capabilities  and  requests  of  software  agents 
in  a  convenient  way.  In  addition,  one  has  to  devise  a  mechanism  for  matching 
descriptions  in  that  language.  This  mechanism  can  then  be  used  by  middle 
agents  to  efficiently  select  relevant  agents  for  some  given  tasks. 

In  the  following,  we  first  elaborate  the  desiderata  of  an  agent  capability 
description  language  (ACDL),  and  propose  such  an  ACDL,  called  Larks,  in 
detail.  Then  we  will  discuss  the  matchmaking  process  using  Larks  and  give  a 
complete  working  scenario  with  some  examples.  We  have  implemented  Larks 
and  the  associated  powerful  matchmaking  process,  and  are  currently  incorpo¬ 
rating  it  within  our  RETSINA  multi-agent  infrastructure  framework  [22].  The 
paper  concludes  with  comparing  our  language  and  the  matchmaking  process 
with  related  works. 


2  Matchmaking  Among  Heterogeneous  Agents 

In  the  process  of  matchmaking  (see  Fig.  1)  are  three  different  kinds  of  collabo¬ 
rating  agents  involved: 

1.  Provider  agents  provide  their  capabilities,  e.g.,  information  search  ser¬ 
vices,  retail  electronic  commerce  for  special  products,  etc.,  to  their  users 
and  other  agents. 

2.  Requester  agents  consume  informations  and  services  offered  by  provider 
agents  in  the  system.  Requests  for  any  provider  agent  capabilities  have  to 
be  sent  to  a  matchmaker  agent. 

3.  Matchmaker  agents  mediate  among  both,  requesters  and  providers,  for 
some  mutually  beneficial  cooperation.  Each  provider  must  first  register 
himself  with  a  matchmaker.  Provider  agents  advertise  their  capabilities 
(advertisements)  by  sending  some  appropriate  messages  describing  the 
kind  of  service  they  offer. 

Every  request  a  matchmaker  receives  will  be  matched  with  his  actual  set 
of  advertisements.  If  the  match  is  successful  the  matchmaker  returns  a 
ranked  set  of  appropriate  provider  agents  and  the  relevant  advertisements 
to  the  requester. 

In  contrast  to  a  broker  agent,  a  matchmaker  does  not  deal  with  the  task  of 
contacting  the  relevant  providers,  transmitting  the  service  request  to  the  service 
provider  and  communicate  the  results  to  the  requester.  This  avoids  data  trans¬ 
mission  bottlenecks,  but  it  might  increase  the  amount  of  interactions  among 
agents. 
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Brokering 


Figure  1:  Service  Brokering  vs.  Matchmaking 

2.1  Desiderata  for  an  Agent  Capability  Description  Lan¬ 
guage 

There  is  an  obvious  need  to  describe  agent  capabilities  in  a  common  language 
before  any  advertisement,  request  or  even  matchmaking  among  the  agents  can 
take  place.  In  fact,  the  formal  description  of  capabilities  is  one  of  the  major 
problems  in  the  area  of  software  engineering  and  AI.  Som®  of  the  main  desired 
features  of  such  a  agent  capability  description  language  are  the  following. 

•  Expressiveness. 

The  language  is  expressive  enough  to  represent  not  only  data  and  knowl¬ 
edge,  but  also  to  describe  the  meaning  of  program  code.  Agent  capabilities 
are  described  at  an  abstract  rather  than  implementation  level.  Most  of 
existing  agents  can  be  distinguished  by  describing  their  capabilities  in  this 
language. 

•  Inferences. 

Inferences  on  descriptions  written  in  this  language  are  supported.  A  user 
can  read  any  statement,  in  the  language,  and  software  agents  are  able  to 
process,  especially  to  compare  any  pair  of  statements  automatically. 

•  Ease  of  Use. 

Every  description  should  not  only  be  easy  to  read  and  understand,  but 
also  easy  to  write  by  the  user.  The  language  supports  the  use  of  domain  or 
common  ontologies  for  specifying  agents  capabilities.  It  avoids  redundant 
work  for  the  user  and  improves  the  readability  of  specifications. 
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•  Application  in  the  Web. 

One  of  the  main  application  domains  for  the  language  is  the  specification 
of  advertisements  and  requests  of  agents  in  the  Web.  The  language  allows 
for  automated  exchange  and  processing  of  information  among  these  agents. 

In  addition,  the  matchmatching  process  on  a  given  set  of  capability  descrip¬ 
tions  and  a  request,  both  written  in  the  chosen  ACDL,  should  be  efficient,  most 
accurate,  not  only  rely  on  keyword  extraction  and  comparison,  and  fully  auto¬ 
mated. 


3  The  Agent  Capability  Description  Language 

Larks 

Representing  capabilities  is  a  difficult  problem  that  has  been  one  of  the  major 
concerns  in  the  areas  of  software  engineering,  AI,  and  more  recently,  in  the 
area  of  internet  computing.  There  are  many  program  description  languages, 
like  VDM  or  Z [28] ,  to  describe  the  functionalities  of  programs.  These  languages 
concern  too  much  detail  to  be  useful  for  the  searching  purpose.  Also,  reading 
and  writing  specifications  in  these  languages  require  sophisticated  training.  On 
the  other  hand,  the  interface  definition  languages,  like  IDL,  WIDL,  go  to  the 
other  extreme  by  omitting  the  functional  descriptions  of  the  services  at  all.  Only 
the  input  and  output  information  are  provided. 

In  AI,  knowledge  description  languages,  like  KL-ONE,  or  KIF  are  meant  to 
describe  the  knowledge  instead  of  the  actions  of  a  service.  The  action  repre¬ 
sentation  formalisms  like  STRIPS  are  too  restrictive  to  represent  complicated 
service.  Some  agent  communication  languages  like  KQML  and  FIPA  concen¬ 
trate  on  the  communication  protocals  (message  types)  between  agents  but  leave 
the  content  part  of  the  language  unspecified. 

In  internet  computing,  various  description  format  are  being  proposed,  no¬ 
tably  the  WIDL  and  the  Resource  Description  Framework(RDF)[27].  Although 
the  RDF  also  aims  at  the  interoperablity  between  web  applications,  it  is  rather 
intended  to  be  a  basis  for  describing  metadata.  RDF  allowes  different  vendors 
to  describe  the  properties  and  relations  between  resources  on  the  Web.  That 
enables  other  programs,  like  Web  robots,  to  easily  extract  relevant  information, 
and  to  build  a  graph  structure  of  the  resources  available  on  the  Web,  without 
the  need  to  give  any  specific  information.  However,  the  description  does  not 
describe  the  functionalities  of  the  Web  services. 

Since  none  of  those  languages  satisfies  our  requirements,  we  propose  an 
ACDL,  called  Larks  (Language  for  Advertisement  and  Request  for  Knowledge 
Sharing)  that  enables  for  advertising,  requesting  and  matching  agent  capabili¬ 
ties.  It  satisfies  the  desiderata  given  in  the  former  section. 

3.1  Specification  in  LARKS 

A  specification  in  Larks  is  a  frame  with  the  following  slot  structure. 
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Context 

Context  of  specification 

Types 

Declaration  of  used  variable  types 

Input 

Declaration  of  input  variables 

Output 

Declaration  of  output  variables 

InConstraints 

Constraints  on  input  variables 

OutConstraints 

Constraints  on  output  variables 

ConcDescriptions 

Ontological  descriptions  of  used  words 

The  frame  slot  types  have  the  following  meaning. 

•  Context. 

The  context  of  the  specification  in  the  local  domain  of  the  agent. 

•  Types. 

Optional  definition  of  the  used  data  types.  If  not  used,  all  data  types  are 
assumed  to  be  defined  in  the  following  slots  for  input  and  output  variables. 

•  Input  and  Output. 

Input/output  variables  for  required  input/output  knowledge  to  describe  a 
capability  of  an  agent:  if  the  input  given  to  an  agent  fits  with  the  specified 
input  declaration  part,  then  the  agent  is  able  to  process  an  output  as 
specified  in  the  output  declaration  part.  Processing  takes  all  specified 
constraints  on  the  input  and  output  variables  into  consideration. 

•  InConstraints  and  OutConstraints. 

Logical  constraints  on  input/output  variables  in  the  input/output  decla¬ 
ration  part.  The  constraints  are  specified  as  Horn  clauses. 

•  ConcDesriptions. 

Optional  description  of  the  meaning  of  words  used  in  the  specification.  The 
description  relies  on  concepts  in  a  given  local  domain  ontology.  Attache- 
ment  of  a  concept  C  to  a  word  w  in  any  of  the  slots  above  is  done  in  the 
form:  w*C.  That  means  that  the  concept  C  is  the  ontological  description 
of  the  word  w.  The  concept  C  is  included  in  the  slot  ConcDescription. 

In  our  current  implementation  we  assume  each  local  domain  ontology  to  be 
written  in  the  concept  language  ITL  (Information  Terminological  Language), 
the  syntax  and  semantics  of  the  Itl  are  given  in  the  appendix.  Section  3.3  gives 
an  example  for  how  to  attach  concepts  in  a  Larks  specification,  and  also  shows 
an  example  domain  ontology  in  ITL.  A  generic  interface  for  using  ontologies 
in  Larks  expressed  in  languages  other  than  Itl  will  be  implemented  in  near 
future. 

Every  specification  in  Larks  can  be  interpreted  as  an  advertisement  as  well 
as  a  request;  this  depends  on  the  purpose  for  which  an  agent  sends  a  specification 
to  some  matchmaker  agent (s).  Every  Larks  specification  must  be  wrapped  up 
in  an  appropriate  KQML  message  by  the  sending  agent  indicating  if  the  message 
content  is  to  be  treated  as  a  request  or  an  advertisement. 
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3.2  Examples  of  Specifications  in  LARKS 

The  following  two  examples  show  how  to  describe  in  Larks  the  capability  to 
sort  a  given  list  of  items,  and  return  the  sorted  list.  Example  3.1  is  the  the  spec¬ 
ification  of  the  capability  to  sort  a  list  of  at  most  100  integer  numbers,  whereas 
in  example  3.2  a  more  generic  kind  of  sorting  real  numbers  or  strings  is  specified 
in  Larks.  Note  that  the  ConcDescriptions  slot  is  empty,  i.e.  the  semantics  of 
the  words  in  the  specification  are  assumed  to  be  known  to  the  matchmaker 


Example  3.1:  Sorting  integer  numbers 


IntegerSort 

Context 

Sort 

Types 

Input 

xs:  ListOf  Integer; 

Output 

ys:  ListOf  Integer; 

InConstraints 

le(length(xs),100); 

Out Constraints 

before(x,y,ys)  <  -  ge(x,y); 
in(x,ys)  <  —  in(x,xs); 

ConcDescriptions 

o 


Example  3.2:  Generic  sort  of  real  numbers  or  strings 


GenericSort 

Context 

Sorting 

Types 

Input 

xs:  ListOf  Real  |  String; 

Output 

ys:  ListOf  Real  |  String; 

InConstraints 

Out Constraints 

before(x,y,ys)  <  -  ge(x,y); 
before(x,y,ys)  <  —  preceeds(x,y); 
in(x,ys)  <  —  in(x,xs); 

ConcDescriptions 

o 


The  next  example  is  a  specification  of  an  agent’s  capability  to  buy  stocks  at 
a  stock  market.  Given  the  name  of  the  stock,  the  amount  of  money  available  for 
buying  stocks  and  the  shares  for  one  stock,  the  agent  is  able  to  order  stocks  at 
the  stock  market.  The  constraints  on  the  order  are  that  the  amount  for  buying 
stocks  given  by  the  user  covers  the  shares  times  the  current  price  for  one  stock. 
After  performing  the  order  the  agent  will  inform  the  user  about  the  stock,  the 
shares,  and  the  gained  benefit. 

Example  3.3:  Selling  stocks  by  a  portfolio  agent 
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sellStock 

Context 

Stock,  StockMarket; 

Types 

Input 

symbol:  StockSymbols; 
yourMoney:  Money; 
shares:  Money; 

Output 

yourStock:  StockSymbols; 
yourShares:  Money; 
yourChange:  Money; 

InConstraints 

yourMoney  >=  shares*currentPrice(symb); 

Out Constraints 

yourChange  =  yourMoney  -  shares*currentPrice(symb); 
yourShares  =  shares;  yourStock  =  symbol; 

ConcDescriptions 

o 


3.3  Using  Domain  Knowledge  in  LARKS 

As  mentioned  before,  Larks  offers  the  option  to  use  application  domain  knowl¬ 
edge  in  any  advertisement  or  request.  This  is  done  by  using  a  local  ontology  for 
describing  the  meaning  of  a  word  in  a  Larks  specification.  Local  ontologies  can 
be  formally  defined  using,  e.g.,  concept  languages  such  as  Itl  (see  Appendix), 
BACK,  LOOM,  CLASSIC  or  KRIS,  a  full-fledged  first  order  predicate  logic, 
such  as  the  knowledge  interchange  format  (KIF),  or  even  the  unified  modeling 
language  (UML). 

The  main  benefit  of  that  option  is  twofold:  (1)  the  user  can  specify  in  more 
detail  what  he  is  requesting  or  advertising,  and  (2)  the  matchmaker  agent  is  able 
to  make  automated  inferences  on  such  kind  of  additional  semantic  descriptions 
while  matching  Larks  specifications,  thereby  improving  the  overall  quality  of 
matching. 

Example  3.4:  Finding  informations  on  computers 

Suppose  that  a  provider  agent  such  as,  e.g.,  HotBot,  Excite,  or  even  a  meta- 
searchbot,  like  SavvySearch  or  MetaCrawler,  advertises  the  capability  to  find 
informations  about  any  type  of  computers.  The  administrator  of  the  agent  may 
specify  that  capability  in  Larks  as  follows. 
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FindComputerlnfo 

Context 

Computer*Computer; 

Types 

InfoList  =  ListOf (model:  Model*ComputerModel, 

brand:  Brand*Brand, 

price:  Price*Money,  color:  Color*Colors); 

Input 

brands:  SetOf  Brand*Brand; 
areas:  SetOf  State; 
processor:  SetOf  CPU*CPU; 
priceLow*LowPrice:  Integer; 
priceHigh*HighPrice:  Integer; 

Output 

Info:  InfoList; 

InConstraints 

Out Constraints 

sorted(Info). 

ConcDescriptions 

Computer  =  (and  Product  (exists  has-processor  CPU) 

(all  has-memory  Memory)  (all  is-model  ComputerModel)); 

LowPrice  =  (and  Price  (ge  1800)(exists  in-currency  aset(USD))); 
HighPrice  =  (and  Price  (le  50000)(exists  in-currency  aset(USD))); 
ComputerModel  = 

aset(HP-Vectra,PowerPC-G3,Thinkpad770,Satellite315); 

CPU  =  aset(Pentium,K6,PentiumII,G3, Merced) 

[Product,  Colors,  Brand,  Money] 

Most  words  in  this  specification  have  been  attached  with  a  name  of  some 
concept  out  of  a  given  ontology.  The  definitions  of  these  concepts  are  included 
in  the  slot  ConcDescriptions.  Concept  definitions  which  were  already  sent 
to  the  matchmaker  are  enclosed  in  brackets.  In  this  example  we  assume  the 
underlying  ontology  to  be  written  in  the  concept  language  Itl.  An  example  for 
such  an  ontology  is  given  in  the  next  section. 

Suppose  that  an  agent  registers  himself  at  some  matchmaker  agent  and  sends 
the  above  specifications  as  advertisements.  The  matchmaker  will  then  treat  that 
agent  as  a  provider  agent,  i.e. ,  an  agent  who  is  capable  to  provide  all  these  kinds 
of  services. 

3.3.1  Example  for  a  Domain  Ontology  in  the  Concept  Language  Itl 

As  mentioned  before,  our  current  implementation  of  Larks  assumes  the  domain 
ontology  to  be  written  in  the  concept  language  ITL. 

The  research  area  on  concept  languages  (or  description  logics)  in  AI  has 
its  origins  in  the  theoretical  deficiencies  of  semantic  networks  in  the  late  70’s. 
KL-ONE  was  the  first  concept  language  providing  a  well-founded  semantic  for  a 
more  native  language-based  description  of  knowledge.  Since  then  different  con¬ 
cept  languages  are  intensively  investigated;  they  are  almost  decidable  fragments 
of  first-order  predicate  logic.  Several  knowledge  representation  and  inference 
systems,  such  as  CLASSIC,  BACK,  KRIS,  or  CRACK,  based  on  such  languages 
are  available. 

Conceptual  knowledge  about  a  given  application  domain,  or  even  common- 
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sense,  is  defined  by  a  set  of  concepts  and  roles  as  terms  in  the  given  concept 
language;  each  term  as  a  definition  of  some  concept  C  is  a  conjunction  of  logical 
constraints  which  are  necessary  for  any  object  to  be  an  instance  of  C.  The 
set  of  terminological  definitions  forms  a  terminology.  Any  canonical  definition 
of  concepts  relies  in  particular  on  a  given  basic  vocabulary  of  words  (primitive 
components)  which  are  not  defined  in  the  terminology,  i.e. ,  their  semantic  is 
assumed  to  be  known  and  consistently  used  across  boundaries. 

The  following  terminology,  is  written  in  the  concept  language  Itl  and  de¬ 
fines  concepts  in  the  computer  application  domain.  It  is  in  particular  used  in 
the  example  3.4  in  the  former  section. 


Product 

Computer 

Notebook 


Brand 

State 

Company 

Colors 

Money 

Price 

LowPrice 

HighPrice 

ComputerModel 

CPU 


(and  (all  is-manufactured-by  Brand)  (atleast  1  is-manufactured-by) 
(all  has-price  Price)) 

(and  Product  (exists  has-processor  CPU)  (all  has-memory  Memory) 
(all  is-model  ComputerModel)) 

(and  Computer  (all  has-price 

(and  (and  (ge  1000)  (le  2999))  (all  in-currency  aset(USD))  ) 

(all  has-weight  (and  kg  (le  5))  (all  is-manufactured-by 
Company)) 

(all  is-model  aset(Thinkpad380,Thinkpad770,Satellite315)))) 

(and  Company  (all  is-located-in  State)) 

(and  (all  part-of  Country)  aset(VA,PA,TX,OH,NY)) 
aset(IBM,Toshiba,HP,Apple,DEC,Dell,  Gateway) 
aset  (Blue,  Green,  Yellow,  Red) 

(and  Real  (all  in-currency  aset(USD,DM,FF,Y,P))) 

Money 

(and  Price  (ge  1800)(exists  in-currency  aset(USD))), 

(and  Price  (le  50000)(exists  in-currency  aset(USD))) 
aset(HP-Vectra,PowerPC-G3,Thinkpad380,Thinkpad770,Satellite315) 
aset  (Pentium, K6,PentiumI I, G3, Merced) 
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3.3.2  Subsumption  Relationships  Among  Concepts 

One  of  the  main  inferences  on  ontologies  written  in  concept  languages  is  the 
computation  of  the  subsumption  relation  among  two  concepts:  A  concept  C 
subsumes  another  concept  C"  if  the  extension  of  C"  is  a  subset  of  that  of  C . 
This  means,  that  the  logical  constraints  defined  in  the  term  of  the  concept  C" 
logically  imply  those  of  the  more  general  concept  C . 

Any  concept  language  is  decidable  if  it  is  for  concept  subsumption  among 
two  concepts  defined  in  that  language.  The  concept  language  Itl  we  use  is 
NP-complete  decidable.  The  well-known  trade-off  between  expressiveness  and 
tractability  of  concept  languages  in  practice  is  surrounded  almost  by  subsump¬ 
tion  algorithms  which  are  correct  but  incomplete.  We  use  an  incomplete  in¬ 
ference  algorithm  for  computing  subsumption  relations  among  concepts  in  Itl. 
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Matchmaker  Agent  x 


Figure  2:  Matchmaking  using  Larks:  An  Overview 


For  the  mechanism  of  subsumption  computation  we  refer  the  reader  to,  e.g., 

[19,  14,  20,  21], 

The  computation  of  subsumption  relationships  among  all  concepts  in  a  ontol¬ 
ogy  yields  a  so-called  concept  hierarchy.  Both,  the  subsumption  computation 
and  the  concept  hierarchy  are  used  in  the  matchmaking  process  (see  section 
4.1.2). 

4  The  Matchmaking  Process  Using  Larks 

As  mentioned  before,  we  differentiate  between  three  different  kinds  of  collab¬ 
orating  information  agents:  provider,  requester  and  matchmaker  agents.  The 
following  figure  shows  an  overview  of  the  matchmaking  process  using  Larks  . 
The  matchmaker  agent  process  a  received  request  in  the  following  main  steps: 

•  Compare  the  request  with  all  advertisements  in  the  advertisement  database. 

•  Determine  the  provider  agents  whose  capabilities  match  best  with  the 
request.  Every  pair  of  request  and  advertisement  has  to  go  through  several 
different  filtering  during  the  matchmaking  process. 

•  Inform  the  requesting  agent  by  sending  them  the  contact  addresses  and 
related  capability  descriptions  of  the  relevant  provider  agents. 

For  being  able  to  perform  a  steady,  just-in-time  matchmaking  process  the  in¬ 
formation  model  of  the  matchmaker  agent  comprises  the  following  components. 
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1.  Advertisement  database  (ADB). 

This  database  contains  all  advertisements  written  in  Larks  the  match¬ 
maker  receives  from  provider  agents. 

2.  Partial  global  ontology. 

The  ontology  of  the  matchmaker  consists  of  all  ontological  descriptions 
of  words  in  advertisements  stored  in  the  ADB.  Such  a  description  is  in¬ 
cluded  in  the  slot  ConcDescriptions  and  sent  to  the  matchmaker  with 
any  advertisement. 

3.  Auxiliary  database. 

The  auxiliary  data  for  the  matchmaker  comprise  a  database  for  word  pairs 
and  word  distances,  basic  type  hierarchy,  and  internal  data. 

Please  note  that  the  ontology  of  a  matchmaker  agent  is  not  necessarily  equal 
to  the  union  of  local  domain  ontologies  of  all  provider  agents  who  are  actually 
registered  at  the  matchmaker.  This  also  holds  for  the  advertisement  database. 
Thus,  a  matchmaker  agent  has  only  partial  global  knowledge  on  available  in¬ 
formation  in  the  overall  multi-agent  system;  this  partial  knowledge  might  also 
be  not  up-to-date  concerning  the  actual  time  of  processing  incoming  requests. 
This  is  due  to  the  fact  that  for  efficiency  reasons  changes  in  the  local  ontology  of 
an  provider  agent  will  not  be  propagated  immediately  to  all  matchmaker  agents 
he  is  registered  at.  In  the  following  we  will  describe  the  matchmaking  process 
using  Larks  in  a  more  detail. 

4.1  The  Filtering  Stages  of  the  Matchmaking  Process 

The  matching  process  of  the  matchmaker  is  designed  with  respect  to  the  follow¬ 
ing  criteria: 

•  The  matching  should  not  be  based  on  keyword  retrieval  only.  Instead, 
unlike  the  usual  free  text  search  engines,  the  semantics  of  requests  and 
advertisements  should  be  taken  into  consideration. 

•  The  matching  process  should  be  automated.  A  vast  amount  of  agents 
appear  and  disappear  in  the  Internet.  It  is  nearly  impossible  for  a  user  to 
manually  search  or  browse  all  agents  capabilities. 

•  The  matching  process  should  be  accurate.  For  example,  if  the  matches 
returned  by  the  match  engine  are  claimed  to  be  exact  match  or  the  plug¬ 
in  match,  those  matches  should  satisfy  the  definitions  of  exact  matching 
and  plug-in  matching. 

•  The  matching  process  should  be  efficient,  i.e. ,  it  should  be  fast. 

•  The  matching  process  should  be  effective,  i.e.,  the  set  of  matches  should 
not  be  too  large.  For  the  user,  typing  in  a  request  and  receiving  hundreds 
of  matches  is  not  necessarily  very  useful.  Instead,  we  prefer  a  small  set  of 
highly  rated  matches  to  a  given  request. 
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To  fulfill  the  matching  criteria  listed  in  the  above  section,  the  matching 
process  is  organized  as  a  series  of  increasingly  stringent  filters  on  candidate 
agents.  That  means  that  matching  a  given  request  into  a  set  of  advertisements 
consists  of  the  following  five  filters  that  we  organize  in  three  consecutive  filtering 
stages: 

1.  Context  Matching 

Select  those  advertisements  in  the  ADB  which  can  be  compared  with  the 
request  in  the  same  or  similar  context. 

2.  Syntactical  Matching 

This  filter  compares  the  request  with  any  advertisement  selected  by  the 
context  matching  in  three  steps: 

(a)  Comparison  of  profiles. 

(b)  Similarity  matching. 

(c)  Signature  matching. 

The  request  and  advertisement  profile  comparison  uses  a  weighted  key¬ 
word  representation  for  the  specifications  and  a  given  term  frequency 
based  similarity  measure  (Salton,  1989).  The  last  two  steps  focus  on  the 
(input/output)  constraints  and  declaration  parts  of  the  specifications. 

3.  Semantical  Matching 

This  final  filter  checks  if  the  input/output  constraints  of  any  pair  of  request 
and  advertisement  logically  match  (see  section  4.1.5). 

For  reasons  of  efficiency  the  context  filter  roughly  prunes  off  advertisements 
which  are  not  relevant  for  a  given  request.  In  the  following  two  filtering  stages, 
syntactical  and  semantical  matching,  the  remaining  advertisements  in  the  ADB 
of  the  matchmaker  are  checked  in  a  more  detail.  All  filters  are  independent  from 
each  other;  each  of  them  narrows  the  set  of  matching  candidates  with  respect 
to  a  given  filter  criteria. 

In  our  current  implementation  the  matchmaker  offers  different  types  and 
modes  of  matching  a  request  to  a  given  set  of  advertisements. 

4.1.1  Different  Types  of  Matching  in  Larks 

Agent  capability  matching  is  the  process  of  determining  whether  an  advertise¬ 
ment  registered  in  the  matchmaker  matches  a  request.  But  when  can  we  say 
two  descriptions  match  against  each  other?  Does  it  mean  that  they  have  the 
same  text?  Or  the  occurrence  of  words  in  one  discription  sufficiently  overlap 
with  those  of  another  discription?  When  both  descriptions  are  totally  different 
in  text,  is  it  still  possible  for  them  to  match?  Even  if  they  match  in  a  given 
sense,  what  can  we  then  say  about  the  matched  advertisements?  Before  we 
go  into  the  details  of  the  matchmaking  process,  we  should  clarify  the  various 
notions  of  matches  of  two  specifications. 
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4. 1.1.1  Exact  Match  Of  course,  the  most  accurate  match  is  when  both 
descriptions  are  equivalent,  either  equal  literally,  or  equal  by  renaming  the  vari¬ 
ables,  or  equal  logically  obtained  by  logical  inference.  This  type  of  matching  is 
the  most  restrictive  one. 

4. 1.1. 2  Plug-In  Match  A  less  accurate  but  more  useful  match  is  the  so- 
called  plug  —  in  match.  Roughly  speaking,  plug-in  matching  means  that  the 
agent  which  capability  description  matches  a  given  request  can  be  ’’plugged  into 
the  place”  where  that  request  was  raised.  Any  pair  of  request  and  advertisement 
can  differ  in  the  signatures  of  their  input/output  declarations,  the  number  of 
constraints,  and  the  constraints  themselves.  As  we  can  see,  exact  match  is  a 
special  case  of  plug-in  match,  i.e. ,  wherever  two  descriptions  are  exact  match, 
they  are  also  plug-in  match. 

A  simple  example  of  a  plug-in  match  is  that  of  the  match  between  a  request 
to  sort  a  list  of  integers  and  an  advertisement  of  an  agent  that  can  sort  both 
list  of  integers  and  list  of  strings.  This  example  is  elaborated  in  section  5. 
Another  example  of  plug-in  match  is  between  the  request  to  find  some  computer 
information  without  any  constraint  on  the  output  and  the  advertisement  of  an 
agent  that  can  provide  these  informations  and  sorts  the  respective  output. 

4. 1.1. 3  Relaxed  Match  The  least  accurate  but  most  useful  match  is  the 
so-called  relaxed  match.  A  relaxed  match  has  a  much  more  weaker  semantic 
interpretation  than  a  exact  match  and  plug-in  match.  In  fact,  relaxed  match 
will  not  tell  whether  two  descriptions  semantically  match  or  not.  Instead  it 
determines  how  close  the  two  descriptions  are  by  returning  just  a  numerical 
distance  value.  Two  descriptions  match  if  the  distance  value  is  smaller  than  a 
preset  threshold  value.  Normally  the  plug-in  match  and  the  exact  match  will 
be  a  special  case  of  the  relaxed  match  if  the  threshold  value  is  not  too  small. 

An  example  of  a  relaxed  match  is  that  of  the  request  to  find  the  place  (or 
address)  where  to  buy  a  Compaq  Pentium233  computer  and  the  capability  de¬ 
scription  of  an  agent  that  may  provide  the  price  and  contact  phone  number  for 
that  computer  dealer. 

Different  users  in  different  situation  may  want  to  have  different  types  of 
matches.  Although  people  usually  may  prefer  to  have  plug-in  matches,  such 
a  kind  of  match  does  not  exist  in  many  cases.  Thus,  people  may  try  to  see 
the  result  of  a  relaxed  match  first.  If  there  is  a  sufficient  number  of  relaxed 
matches  returned  a  refined  search  may  be  performed  to  locate  plug-in  matching 
advertisements.  Even  when  people  are  interested  in  a  plug-in  match  for  their 
requests  only,  the  computational  costs  for  this  type  of  matching  might  outweigh 
its  benefits. 

As  mentioned  above  we  have  five  different  matching  filters: 

1.  context  matching 

2.  profile  comparison 
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3.  similarity  matching 

4.  signature  matching 

5.  semantical  matching 

The  first  three  filters  are  meant  for  relaxed  matching,  and  the  signature  and 
semantical  matching  filter  are  meant  for  plug-in  matching.  Please  note,  that 
the  computational  costs  of  these  filters  are  in  increasing  order.  Users  may  select 
any  combinations  of  these  filters  according  their  demand.  Since  the  similarity 
filter  also  performs  intensive  computation  one  may  just  select  the  context  filter 
and  the  profile  filter  if  efficiency  is  of  major  concern. 

Based  on  the  given  notions  of  matching  we  did  implement  four  different 
modes  of  matching  for  the  matchmaker: 

1.  Complete  Matching  Mode.  All  filtering  stages  are  considered. 

2.  Relaxed  Matching  Mode.  The  first  two  filtering  stages  are  considered 
except  signature  matching,  i.e. ,  the  context,  profile  and  similarity  filter 
only. 

3.  Profile  Matching  Mode.  Only  the  context  matching  and  comparison 
of  profiles  is  done. 

4.  Plug-In  Matching  Mode.  In  this  mode,  the  matchmaker  performs  the 
signature  and  semantical  matching. 

As  said  above,  the  matching  process  proceeds  in  different  filtering  stages.  If 
the  considered  advertisement  and  request  contain  conceptual  attachments  (on¬ 
tological  description  of  used  words),  then  in  most  of  the  filtering  stages  (except 
for  the  comparison  of  profiles)  we  need  a  way  to  determine  the  semantic  distance 
between  the  defined  concepts.  For  that  we  use  the  computation  of  subsumption 
relationships  and  a  weighted  associative  network. 

4.1.2  Computation  of  Semantic  Distances  Among  Concepts 

We  have  presented  the  notion  of  concept  subsumption  in  section  3.3.2.  But  the 
concept  subsumption  gives  only  a  generalization/specialization  relation  based 
on  the  definition  of  the  concepts  via  roles  and  attribute  sets.  In  particular  for 
matchmaking  the  identification  of  additional  relations  among  concepts  is  very 
useful  because  it  leads  to  a  deeper  semantic  understanding.  Moreover,  since 
the  expressivity  of  the  concept  language  Itl  is  restrictive  so  that  performance 
can  be  enhanced,  we  need  some  way  to  express  additional  associations  among 
concepts. 

For  this  purpose  we  use  a  so-called  weighted  associative  network,  that  is  a 
semantic  network  with  directed  edges  between  concepts  as  nodes.  Any  edge 
denotes  the  kind  of  a  binary  relation  among  two  concepts,  and  is  labeled  in 
addition  with  a  numerical  weight  (interpreted  as  a  fuzzy  number) .  The  weight 
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indicates  the  strength  of  belief  in  that  relation,  since  its  real  world  semantics 
may  vary1.  We  assume  that  the  semantic  network  consists  of  three  kinds  of 
binary,  weighted  relationships:  (1)  generalization,  (2)  specialization  (as  inverse 
of  generalization),  and  (3)  positive  association  among  concepts  (Fankhauser 
et  ah,  1991).  The  positive  association  is  the  most  general  relationship  among 
concepts  in  the  network  indicating  them  as  synonyms  in  some  context.  Such  a 
semantic  network  is  called  an  associative  network  (AN). 

In  our  implementation  we  create  an  associative  network  by  using  the  con¬ 
cept  hierarchy  of  a  given  terminology  defined  in  the  concept  language  Itl.  All 
subsumption  relations  in  this  concept  hierarchy  are  used  for  setting  the  gen¬ 
eralization  and  specialization  relations  among  concepts  in  the  corresponding 
associative  network.  Positive  associations  may  be  set  by  the  administrator  or 
user.  Positive  association,  generalization  and  specialization  are  transitive. 

As  mentioned  above,  every  edge  in  the  associative  network  is  labeled  with 
a  fuzzy  weight.  These  weights  are  set  by  the  user  or  automatically  by  default. 
The  distance  between  two  concepts  in  an  associative  network  is  then  computed 
as  the  strength  of  the  shortest  path  among  them.  Combining  the  strength  of 
each  relation  in  this  path  is  done  by  using  the  following  triangular  norms  for 
fuzzy  set  intersections  (Kruse  et  ah,  1991): 

Ti(a,f3)  =  max{0,  a  +  [3  —  1}  n  =  —  1 
T2{a ,  f3)  =  a  ■  f3  n  =  0 

Ts(a,/3)  =  min{a,/3}  n  =  oo 

Since  we  have  three  different  kinds  of  relationships  among  two  concepts  in 
an  AN  the  kind  and  strength  of  a  path  among  two  arbitrary  concepts  in  the 
network  is  determined  as  shown  in  the  following  tables.  For  a  formal  discussion 
of  that  issue  we  refer  to  the  work  of  Fankhauser  et  al.  (1991),  Kracker  (1992), 
and  Fankhauser  and  Neuhold  (1992). 
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Table  1:  Kind  of  paths  in  an  AN. 
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Table  2:  Strength  of  paths  in  an  AN. 


For  all  0  <  a,/3  <  1  holds  that  Ti(a,f3)  <  72(0:,/?)  <  73(0, /3).  Each  tri¬ 
angular  norm  is  monotonic,  commutative  and  associative,  and  can  be  used  as 
axiomatic  sceletons  for  fuzzy  set  intersection.  We  restrict  ourselves  to  a  pes¬ 
simistic,  neutral,  and  optimistic  t-norm  71,72  and  73,  respectively. 

Since  these  triangular  norms  are  not  mutually  associative  the  strength  of  a 
path  in  an  associative  network  depends  on  the  direction  of  strength  composition. 
This  asymmetry  in  turn  might  lead  to  unintuitive  derived  results:  Consider,  e.g., 
a  path  consisting  of  just  three  relations  among  four  concepts  C 1,  C'2,  C3,  C4  with 

1The  relationships  are  fuzzy,  and  one  cannot  possibly  associate  all  concepts  with  each 
other. 
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Ci  =>g, 0.6  c2  =>S) 0.8  C3  =>P)0.9  C4.  It  holds  that  r2(r3(0.6,  0.8),  0.9)  =  0.54,  but 
the  strength  of  the  same  path  in  opposite  direction  is  72(72(0. 9,  0.8),  0.6)  =  0.43. 
According  to  Fankhauser  and  Neuhold  (1992)  we  can  avoid  this  asymmetry  by 
imposing  a  precedence  relation  (3  >  2  >  1)  for  strength  combination  (see  Table 
3). 
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Table  3:  Computational  precedence  for  the  strength  of  a  path. 

The  computation  of  semantic  distances  among  concepts  is  used  in  most  of 
the  filtering  stages  of  the  matching  process.  We  will  now  describe  each  of  the 
filters  in  detail. 

4.1.3  Context  Matching 

It  is  obvious  that  any  matching  of  two  specifications  has  to  be  in  an  appropriate 
context.  Suppose  a  provider  agent  advertises  to  sell  several  different  types  of 
products,  like  cars,  computers,  shoes,  etc.  Further  assume  that  all  his  adver¬ 
tisements  include  the  only  input  variable  declaration:  brand:  SetOf  Brand; 
But  what  is  meant  by  the  type  ’Brand’  in  the  context  of  any  specification  of 
a  capability  of  finding  a  particular  item?  Without  any  additional  knowledge 
about  the  particular  context,  a  request  to  find  information  about  a  particular 
item,  like  computers,  would  match  with  all  product  advertisements. 

In  Larks  there  are  two  possibilities  to  deal  with  this  problem  which  is  con¬ 
nected  to  the  well-known  ontological  mismatch  problem.  First,  the  Context  slot 
in  a  specification  S  contains  a  (list  of)  words  denoting  the  domain  of  discourse 
for  matching  S  with  any  other  specification.  When  comparing  two  specifications 
it  is  assumed  that  their  domains,  means  their  context,  are  the  same  (or  atleast 
sufficiently  similar)  as  long  as  the  real-valued  distances  between  these  words  do 
not  exceed  a  given  threshold2 .  The  matching  process  only  proceeds  if  that  is 
true. 

Second,  every  word  in  a  Larks  specification  may  be  associated  with  a  con¬ 
cept  in  a  given  domain  ontology.  Again,  if  the  context  of  both  specifications 
turned  out  to  be  sufficiently  similar  in  the  step  before  then  the  concept  defini¬ 
tions  describe  the  meaning  of  the  words  they  are  attached  to  in  a  more  detail 
in  the  same  domain.  In  this  case,  two  concepts  with  same  name  but  different 
definitions  will  be  stored  separately  by  extending  each  concept  name  by  the 
identifier  of  the  agent  who  did  send  this  concept. 

To  summarize,  the  context  matching  consists  of  two  consecutive  steps: 

2  Any  distance  between  two  words  is  computed  by  an  appropriate  word  distance  function 
using  the  auxiliary  database  of  the  matchmaker. 
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1.  For  every  pair  of  words  u,  v  given  in  the  context  slots  compute  the  real¬ 
valued  word  distances  dw(u,  v)  £[0,1].  Determine  the  most  similar  matches 
for  any  word  u  by  selecting  words  v  with  the  minimum  distance  value 
dw(u,v).  These  distances  must  not  exceed  a  given  threshold. 

2.  For  every  pair  of  most  similar  matching  words,  check  that  the  semantic 
distance  among  the  attached  concepts  does  not  exceed  a  given  threshold. 

4.1.4  Syntactical  Matching 

4. 1.4.1  Comparison  of  Profiles  The  comparison  of  two  profiles  relies  on  a 
standard  technique  from  the  Information  Retrieval  area,  called  term  frequency- 
inverse  document  frequency  weighting  (TF-IDF)  (see  Salton,  1989).  According 
to  that,  any  specification  in  Larks  is  treated  as  a  document. 

Each  word  w  in  a  document  Req  is  weighted  for  that  document  in  the  fol¬ 
lowing  way.  The  number  of  times  w  occurs  throughout  all  documents  is  called 
the  document  frequency  df(w)  of  w.  The  used  collection  of  documents  is  not 
unlimited,  such  as  the  advertisement  database  of  the  matchmaker. 

Thus,  for  a  given  document  d,  the  relevance  of  d  based  on  a  word  w  is 
proportional  to  the  number  wf(w,  d)  of  times  the  word  w  occurs  in  d  and  inverse 
proportional  to  df(w).  A  weight  h(w,d)  for  a  word  in  a  document  d  out  of  a  set 
D  of  documents  denotes  the  significance  of  the  classification  of  w  for  d,  and  is 
defined  as  follows: 

h(w,  d)  =  wf(w,  d)  ■  log(  jjr^j). 

The  weighted  keyword  representation  wkv(d,  V)  of  a  document  d  contains 
for  every  word  w  in  a  given  dictionary  V  the  weight  h(w,  d)  as  an  element.  Since 
most  dictionaries  provide  a  huge  vocabulary  we  cut  down  the  dimension  of  the 
vector  by  using  a  fixed  set  of  appropriate  keywords  determined  by  heuristics 
and  the  set  of  keywords  in  Larks  itself. 


The  similarity  dps(Req,  Ad)  of  a  request  Req  and  an  advertisement  Ad  under 
consideration  is  then  calculated  by  : 


dps(Req,  Ad) 


Req  •  Ad 
\Req\  ■  \Ad\ 


where  Req  •  Ad  denotes  the  inner  product  of  the  weighted  keyword  vectors. 
If  the  value  dps(Req,  Ad)  does  exceed  a  given  threshold  [3  £  R  the  matching 
process  continues  with  the  following  steps. 


The  matchmaker  then  checks  if  the  declarations  and  constraints  of  both 
specifications  for  a  request  and  advertisement  are  sufficiently  similar.  This  is 
done  by  a  pairwise  comparison  of  declarations  and  constraints  in  two  steps: 

1.  Similarity  matching  and 

2.  Signature  matching 
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4. 1.4. 2  Similarity  Matching  Let  Ei,Ej  be  variable  declarations  or  con¬ 
straints,  and  S(E)  the  set  of  words  in  E.  The  similarity  among  two  expressions 
Ei  and  Ej  is  determined  by  pairwise  computation  of  word  distances  as  follows: 

SimiEi^j)  =  1  -  ((  E  dw(u,v))/\S(Ei)  x  S(Ej)\)) 

(u,v)eS(Ei)xS(Ej) 

The  similarity  value  Sim(Sa ,  Sb)  among  two  specifications  Sa  and  Sb  in 
Larks  is  computed  as  the  average  of  the  sum  of  similarity  computations  among 
all  pairs  of  declarations  and  constraints: 

Sim(Sa,Sb)  = 

E  Sim(Ei,Ej)/\(D(Sa)xD(Sb))U(C(Sa)xC(Sb))\ 

(L)£J)e(D(s«)xf(5i))c'(c(s0)xc(Si)) 

with  D(S)  and  C'(S)  denoting  the  input/output  declaration  and  input/output 
constraint  part  of  a  specification  S  in  Larks,  respectively. 

4. 1.4. 3  Signature  Matching  Consider  the  declaration  parts  of  the  request 
and  the  advertisement,  and  determine  pairwise  if  their  signatures  of  the  (input 
or  output)  variable  types  match  following  the  type  inference  rules  given  below. 

Definition  4.1:  Subtype  Inference  Rules 

Consider  two  types  t\  and  t2  as  part  of  an  input  or  output  variable  declaration 
part  (in  the  form  Input  v  :  tp,  or  Output  v  :t2',)  in  a  Larks  specification. 

1.  Type  t\  is  a  subtype  of  type  t2  (denoted  as  t\  Sst  t2)  if  this  can  be  deduced 
by  the  following  subtype  inference  rules. 

2.  Two  types  ti,t2  are  equal  (tb  =st  t2)  if  C  Sst  t2  and  t2  Sst  t\  with 

(a)  t\  =st  t2  if  they  are  identical  t\  =  t2 

(b)  t\  |  t2  =st  t2  |  C  (commutative) 

(c)  (ti  |  t’z)  |  ^3  =  ti  |  {t’2  |  tz)  (associative) 

Subtype  Inference  Rules: 

1)  C  Sst  t2  if  t2  is  a  type  variable 

I\  - St  t2 

>  h  <,t  h 

3)  t\ , t2  are  sets, 

C  c  U 

tl  Sst  1 2 

4)  tl  Sst  tl  |  t2 

5)  t2  Sst  tl  1 12 
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6) 


tl  diet  1 2,  Si^,sfS2 
(tl,Sl)  Sst  (t2,S2) 


7) 


fl  diet  h,  S\SstS2 
1 1  S1  Cist  t’2  -S'2 


8) 

9) 


tl  Sxt  to 


SetOf(ti)  Sst  SetOf  (f2) 

_ 1 1  -<xt  t2 _ 

ListOf(ti)  S-st  List0f(f2 


Matching  of  two  signatures  sig  and  sig'  is  done  by  a  binary  string-valued 
function  fsm  on  signatures  with 


fsm(sig,  sig') 


sub 

sig'  Sst  -sig 

Sub 

sig  Sst  -sig' 

eq 

sig  =st  sig' 

disj 

else 

Having  described  both  filters  of  the  syntactical  matching  we  now  define  the 
meaning  of  syntactical  matching  of  two  specifications  written  in  Larks. 


Definition  4.2:  Syntactical  matching  of  specifications  in  Larks 

Consider  two  specifications  Sa  and  Sb  in  Larks  with  n k  input  declarations,  raj 
output  declarations,  and  Vk  constraints  nj,,  mk  £N,i£  {a,  &},  two  declarations 
Di,  Dj,  and  constraints  C\,  C'j  in  these  specifications,  and  V  a  given  dictionary 
for  the  computation  of  weighted  keyword  vectors.  Let  /?,  7,  9  be  real  threshold 
values  for  profile  comparison  and  similarity  matching. 

•  The  declarations  Di  and  Di  syntactically  match  if  they  are  suffi¬ 
ciently  similar: 


Sim(Di ,  Dj)  >  7  A  fsm(Di,Dj)  7^  disj. 

The  constraints  C'i  and  C'j  syntactically  match  if  they  are  sufficiently 
similar: 


Sim(Ci,Cj)  >7. 

If  both  words  in  every  pair  (u,v)  £  S(Ei)  x  S(Ej)  of  most  similar  words 
are  associated  with  a  concept  C  and  C" ,  respectively,  then  the  distance 
among  C  and  C"  in  the  so-called  associative  network  of  the  matchmaker 
must  not  exceed  a  given  threshold  value  9. 

The  syntactical  match  of  two  declarations  or  constraints  is  denoted  by  a 
boolean  predicate  Synt. 
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•  The  specifications  Sa  and  Sb  syntactically  match  if 

1.  their  profiles  match,  i.e. ,  dps(Sa,  Sb)  >  /?,  and 

2.  for  each  declaration  or  constraint  Ei,  i  E  {1,  ...na}  in  the  declaration 
or  constraint  part  of  Sa  there  exists  a  most  similar  matching  declara¬ 
tion  or  constraint  Ej,  j  E  {1,  rib}  in  the  declaration  or  constraint 
part  of  Sb  such  that 

Synt(Ei,Ej)  A  Sim(Ei,  Ej)  =  max{Sim(Ei,  Ey),  y  E  {1,  rib}} 
(Analogous  for  each  declaration  or  constraint  in  Sb-) 

3.  for  each  pair  of  declarations  determined  in  (1.)  the  matching  of  their 
signatures  is  of  the  same  type,  i.e.,  for  each  ( £)s- ,  Dj)  in  (1.)  it  holds 
that  the  value  fsm(Di,  Dj)  is  the  same,  and 

4.  the  similarity  value  Sim(Sa,  Sb)  exceeds  a  given  threshold. 


4.1.5  Semantical  Matching 

By  using  the  syntactical  filter  many  matches  might  be  found  in  a  large  agent 
society.  Hence,  it  is  important  to  use  some  kind  of  semantic  information  to 
narrow  the  search,  and  to  pin  down  more  precise  matches. 

The  most  common  and  natural  interpretation  for  a  specification  (even  for 
a  software  program)  is  using  sets  of  pre-  and  post-conditions,  denoted  as  Pres 
and  Posts,  respectively.  In  a  simplified  notation,  any  specification  S  can  be 
represented  by  the  pair  (Pres,  Posts). 

Definition  4.3:  Semantical  matching  of  two  specifications 
Consider  two  specifications  S(Pres ,  Posts)  and  T(Prex ,  Post?)- 

The  specification  S  semantically  matches  the  specification  T  if 
( Pres  =S  Prex)  A  ( Postx  =S  Posts) 

That  means,  the  set  of  pre-conditions  of  S  logically  implies  that  of  T,  and 
the  set  of  post-conditions  of  S  is  logically  implied  by  that  of  T. 


The  problem  in  performing  the  semantical  matching  is  that  the  logical  im¬ 
plication  is  not  decidable  for  first  order  predicate  logic,  and  even  not  for  a  set 
of  Horn  clauses.  To  make  the  matching  process  tractable  and  feasible,  we  have 
to  decide  on  the  expressiveness  of  the  language  used  to  represent  the  pre-  and 
post-  conditions,  and  to  choose  a  relation  that  is  weaker  than  logical  impli¬ 
cation.  The  (^-subsumption  relation  among  two  constraints  C,  C"  (denoted  as 
C  Sff  C')  appears  to  be  a  suitable  choice  for  semantical  matching,  because  it  is 
computationally  tractable  and  semantically  sound. 
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PreS 


PreT 


Figure  3:  Plug-In  Match  of  Specifications:  T  plugs  into  S. 


4. 1.5.1  Plug-in  Semantical  Matching  in  LARKS  It  is  proven  in  the 
software  engineering  area  that  if  the  condition  of  semantical  matching  in  defi¬ 
nition  4.3  holds,  and  the  signatures  of  both  specifications  match,  then  T  can  be 
directly  used  in  the  place  of  S,  i.e. ,  T  plugs  in  S  (see  figure  4.1.5). 

Definition  4.4:  Plug-In  semantical  matching  of  two  specifications 

Given  two  specifications  Sped  and  Spec'2  in  Larks  then  Sped  plug-in  matches 
Spec‘2  if 

•  Their  signatures  matches  (see  section  4. 1.4. 2). 

•  For  every  clau$p  Cl  in  the  set  of  input  constraints  of  Sped  there  is  a 
clause  C 2  in  the  set  of  input  constraint  of  Spec2  such  that  Cl  Sff  C 2. 

•  For  every  clause  C 2  in  the  set  of  output  constraints  of  Spec2  there  is  a 
clause  Cl  in  the  set  of  output  constraints  of  Sped  such  that  C 2  <s  Cl. 

where  Sff  denotes  the  0-subsumption  relation  between  constraints. 


4. 1.5. 2  0-Subsumption  between  Constraints  One  suitable  selection  of 
the  language  and  the  relation  ifi  the  (definite  program)  clause  and  the  the 
so-called  0-subsumpt.ion  relation  between  clauses,  respectively.3  In  the  fol¬ 
lowing  we  will  only  consider  Horn  clauses.  A  general  form  of  Horn  clause  is 

3  A  clause  is  a  finite  set  of  literals ,  which  is  treated  as  the  universally  quantified  disjunction 
of  those  literals.  A  literal  may  be  positive  or  negative.  A  positive  literal  is  an  atom ,  a  negtive 
literal  is  the  negation  of  an  atom.  A  definite  program  clause  is  a  clause  with  one  positive 
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do  V  (_1di)  V  ...  V  (_ian),  where  each  cq,i  E  {1  is  an  atom.  This 

is  equivalent  to  do  V  -i(di  A  ...  A  an),  which  in  turn  is  equivalent  to 
(di  A  ...  A  a„)  =>•  do).4  We  adopt  the  standard  notation  for  that  clause  as 
do  i —  di ,  ...  ,  dn;  in  PROLOG  the  same  clause  is  written  as  do  dj,  ...  ,  an. 

Examples  of  definite  program  clauses  are 

•  Date. year  >  1995,  sorted(computerlnfo), 

•  before(x,y,ys)  ^  ge(x,y),  and 

•  scheduleM  eeting(groupl,  group2,  interval,  meeting  Duration,  meetTime)  <— 
belongs(pl,  group  1),  belongs(p2,  group2),  subset  (meetTime ,  interval),  length(meetTime) 
meeting  Duration,  available(pl,  meetTime) ,  available(p2,  meetTime) . 


We  say  that  a  clause  C  ^-subsumes  another  clause  D  (denoted  as  C  Pg  D) 
if  there  is  a  substitution  9  such  that  C9  C  D.  C'  and  D  are  0-equivalent  if 
C  Tg  D  and  D 
preceqgC . 

Examples  of  0-subsumption  between  clauses  are 

•  P(a)  A-  Q(a)  Tg  P(X)  <-Q(X) 

•  P(X)  <-Q(X),R{X)  Tg  P{X)<-Q{X). 

Since  a  single  clause  is  not  expressive  enough,  we  need  to  use  a  set  of  clauses 
to  express  the  pre  and  post  conditions  (i.e. ,  the  input  and  output  constraints) 
of  a  specification  in  Larks.  A  set  of  clauses  is  treated  as  a  conjunction  of  those 
clauses. 

Subsumption  between  two  set  of  clauses  is  defined  in  terms  of  the  subsump¬ 
tion  between  single  clauses.  More  specifically,  let  S  and  T  be  such  sets  of  clauses. 
Then,  we  define  that  S  0-subsumes  T  if  every  clause  in  T  is  0-subsumed  by  a 
clause  in  S. 

There  is  a  complete  algorithm  to  test  the  0-subsumption  relation,  which  is 
in  general  NP-complete  but  polynomial  in  certain  cases.  On  the  other  hand, 
0-subsumption  is  a  weaker  relation  than  logical  implication,  i.e.,  from  C  Tg  D 
we  can  only  infer  that  C  logically  implies  D  but  not  vice  versa.5 

5  Examples  of  Matchmaking  using  Larks 

Consider  the  specifications  ’IntegerSort’  and  ’GenericSort’  (see  example  3.1,  3.2) 
as  a  request  of  sorting  integer  numbers  and  an  advertisement  for  some  agent’s 

literal  and  zero  or  more  negative  literals.  A  definite  goal  is  a  clause  without  positive  literals. 
A  Horn  clause  is  either  a  definite  program  clause  or  a  definite  goal. 

4The  literal  ao  is  called  the  head  of  the  clause,  and  (ai  A  ...  A  an)  is  called  the  body  of 
the  clause. 

5Please  also  note  that  the  0-subsumption  relation  is  similar  to  the  query  containment  in 
database.  When  advertisements  are  database  queries,  specification  matching  is  reduced  to  the 
problem  of  query  containment  testing. 
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capability  of  sorting  real  numbers  and  strings,  respectively. 


IntegerSort 

Context 

Sort 

Types 

Input 

xs:  ListOf  Integer; 

Output 

ys:  ListOf  Integer; 

InConstraints 

le(length(xs) ,  100) ; 

Out Constraints 

before(x,y,ys)  <  -  ge(x,y); 
in(x,ys)  <  —  in(x,xs); 

ConcDescript ions 

GenericSort 

Context 

Sorting 

Types 

Input 

xs:  ListOf  Real  |  String; 

Output 

ys:  ListOf  Real  |  String; 

InConstraints 

Out Constraints 

before(x,y,ys)  <  -  ge(x,y); 
before(x,y,ys)  <  —  preceeds(x,y); 
in(x,ys)  <  —  in(x,xs); 

ConcDescript ions 

Assume  that  the  requester  and  provider  agent  sends  the  request  IntegerSort 
and  advertisment  GenericSort  to  the  matchmaker,  respectively.  Figure  5  de¬ 
scribes  the  overall  matchmaking  process  for  that  request. 

1.  Context  Matching 

Both  words  in  the  Context  declaration  parts  are  sufficiently  similar.  We 
have  no  referenced  concepts  to  check  for  terminologically  equity.  Thus, 
the  matching  process  proceeds  with  the  following  two  filtering  stages. 

2.  Syntactical  Matching 


(a)  Comparison  of  Profiles 

According  to  the  result  of  TF-IDF  method  both  specifications  are 
sufficiently  similar: 

(b)  Signature  Matching 

Consider  the  signatures  t\=  (ListOf  Integer)  and  G=  (ListOf 
Real|String).  Following  the  subtype  inference  rules  9.,  4.  and  1. 
it  holds  that  t\  Sst  G,  but  not  vice  versa,  thus  fsm(Dn,D 21)  = 
sub.  Analogous  for  fsm(Di2 ,  -D22)  =  sub. 
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“Find  agent  that 
can  sort  integer 
.  numbers” 


Requester  Ag 

ent 

IntegerSort 

J 

Ranked  Set  of  Agents 
with  capability  to  sort 
integer  numbers 


Context 

Syntactical 

Semantical 

Matching 

Matching 

Matching 

Figure  4:  An  Example  of  Matchmaking  using  Larks 


(c)  Similarity  Matching 

Using  the  current  auxiliary  database  for  word  distance  values  simi¬ 
larity  matching  of  constraints  yields: 
le(lengtli(xs),100))  null  =  1.0 

before(x,y,ys)  <  —  ge(x,y)  in(x,ys)  <  —  in(x,xs)  =  0.5729 

in(x,ys)  <  —  in(x,xs)  before(x,y,ys)  <  —  preceeds(x,y))  =  0.4375 

before(x,y,ys)<  —  ge(x,y))  before(x,y,ys)  <  —  preceeds(x,y))  =  0.28125 

The  similarity  of  both  specifications  is  computed  as: 

,S7m(IntegerSort,  GenericSort)  =  0.64. 

3.  Semantical  Matching 

The  advertisement  GenericSort  also  matches  semantically  with  the  re¬ 
quest  IntegerSort,  because  the  set  of  input  constraints  of  IntegerSort  6- 
subsumes  that  of  GenericSort,  and  the  output  constraints  of  GenericSort 
^-subsumes  that  of  IntegerSort.  Thus  GenericSort  plugs  into  IntegerSort. 
Please  note  that  this  does  not  hold  vice  versa. 


6  Related  works 

Agent  matchmaking  has  been  actively  studied  since  the  inception  of  software 
agent  research.  The  earlist  matchmaker  we  are  aware  of  is  the  ABSI  facilitator, 
which  is  based  on  the  KQML  specification  and  uses  the  KIF  as  the  content 
language.  The  KIF  expression  is  basically  treated  like  the  Horn  clauses.  The 
matching  between  the  advertisement  and  request  expressed  in  KIF  is  the  simple 
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unification  with  the  equality  predicate.  Matchmaking  using  Larks  performs 
better  than  ABSI  in  both,  the  language  and  the  matching  process.  The  plug-in 
matching  in  Larks  uses  the  0-subsumption  test,  which  select  more  matches 
that  are  also  semantically  matches. 

The  SHADE  and  COINS[17]  are  matchmakers  based  on  KQML.  The  content 
language  of  COINS  allowes  for  the  free  text  and  its  matching  algorithm  utilizes 
the  tf-idf.  The  contect  language  of  SHADE  matchmaker  consists  of  two  parts, 
one  is  a  subset  of  KIF,  another  is  a  structured  logic  representation  called  MAX. 
MAX  use  logic  frames  to  declaratively  store  the  knowledge.  SHADE  uses  a 
frame  like  representation  and  the  matcher  use  the  prolog  like  unifier. 

A  more  recent  service  broker-based  information  system  is  InfoSleuth[10, 
11].  The  content  language  supported  by  InfoSleuth  is  KIF  and  the  deductive 
database  language  LDL++,  which  has  a  semantics  similar  to  Prolog.  The  con¬ 
straints  for  both  the  user  request  and  the  resource  data  are  specified  in  terms 
of  some  given  central  ontology.  It  is  the  use  of  this  common  vocabulary  that 
enables  the  dynamic  matching  of  requests  to  the  available  resources.  The  ad¬ 
vertisements  specify  agents’  capabilities  in  terms  of  one  or  more  ontologies.  The 
constraint  matching  is  an  intersection  function  between  the  user  query  and  the 
data  resource  constraints.  If  the  conjunction  of  all  the  user  constraints  with  all 
the  resource  constraints  is  satishable,  then  the  resource  contains  data  which  are 
relevant  to  the  user  request. 

A  somewhat  related  research  area  is  the  research  on  information  mediators 
among  heterogenous  information  systems[23][l].  Each  local  information  system 
is  wrapped  by  a  so-called  wrapper  agent  and  their  capabilities  are  described  in 
two  levels.  One  is  what  they  can  provide,  usually  described  in  the  local  data 
model  and  local  database  schema.  Another  is  what  kind  of  queries  they  can 
answer;  usually  it  is  a  subset  of  the  SQL  language.  The  set  of  queries  a  service 
can  accept  is  described  using  a  grammar-like  notation.  The  matching  between 
the  query  and  the  service  is  simple:  it  just  decides  whether  the  query  can  be 
generated  by  this  grammar.  This  area  emphasizes  the  planning  of  database 
queries  according  to  heterogeneous  information  systems  not  providing  complete 
SQL  sevices.  Those  systems  are  not  supposed  to  be  searched  for  among  a  vast 
number  of  resources  on  the  Internet. 

The  desfription  of  capabilities  and  matching  are  not  only  studied  in  the  agent 
community,  but  also  in  other  related  areas. 

6.1  Works  related  with  capability  description 

The  problem  of  capability  and  service  descriptions  can  be  tackled  at  least  from 
the  following  different  approaches: 

1.  Software  specification  techniques. 

Agents  are  computer  programs  that  have  some  specific  characteristics. 
There  are  numerous  work  for  software  specifications  in  formal  methods, 
like  model-oriented  VDM  and  Z [28] ,  or  algebraic-oriented  Larch.  Although 
these  languages  are  good  at  describing  computer  programs  in  a  precise 
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way,  the  specification  usually  contains  too  much  details  to  be  of  interests 
to  other  agents.  Besides,  those  existing  languages  are  so  complex  that  the 
semantic  comparison  between  the  specifications  is  impossible.  The  reading 
and  writing  of  these  specifications  also  require  substantial  training. 

2.  Action  representation  formalisms. 

Agent  capability  can  be  seen  as  the  actions  that  the  agents  perform.  There 
are  a  number  of  action  representation  formalisms  in  AI  planning  like  the 
classical  one  the  STRIPS.  The  action  representation  formalism  are  inad¬ 
equate  in  our  task  in  that  they  are  propositional  and  not  involving  data 
types. 

3.  Concept  languages  for  knowledge  representation. 

There  are  various  terminological  knowledge  representation  languages.  How¬ 
ever,  ontology  itself  does  not  describe  capabilities.  On  the  other  hand,  it 
provides  auxiliary  concepts  to  assist  the  specification  of  the  capabilities  of 
agents. 

4.  Database  query  capability  description. 

The  database  query  capability  description  technique  is  developed  as  an 
attempt  to  describe  the  information  sources  on  the  Internet,  such  that 
an  automated  integration  of  information  is  possible.  In  this  approach 
the  information  source  is  modeled  as  a  database  with  restricted  quering 
capabilities. 

6.2  Works  related  with  service  retrieval 

There  are  three  broad  approaches  to  service  retrieval.  One  is  the  information 
retrieval  techniques  to  search  for  relevant  information  based  on  text,  another 
is  the  software  component  retrieval  techniques[26][8][13]  to  search  for  software 
components  based  on  software  specifications.  The  third  one  is  to  search  for  web 
resources  that  are  typically  described  as  database  models[18][23]. 

In  the  software  component  search  techniques,  [26]  defined  several  notions  of 
matches,  including  the  exact  match  and  the  plug-in  match,  and  formally  proved 
the  relationship  between  those  matches.  [8]  propsed  to  use  a  sequence  of  filters 
to  search  for  software  components,  for  the  purpose  to  increase  the  efficiency  of 
the  search  process.  [13]  computed  the  distance  between  similar  specifications. 
All  these  work  are  based  on  the  algebraic  specification  of  computer  programs. 
No  concept  description  and  concept  hierarchy  are  considered  in  their  work. 

In  Web  resource  search  techniques,  [18]  proposed  a  method  to  look  for  better 
search  engines  that  may  provide  more  relevant  data  for  the  user  concerns,  and 
rank  those  search  engines  according  to  their  relevance  to  user’s  query.  They  pro¬ 
pose  the  directory  of  services  to  record  descriptions  of  each  information  server, 
called  a  server  description.  A  user  sends  his  query  to  the  directory  of  services, 
which  determins  and  ranks  the  servers  relevant  to  the  user’s  request.  Both  the 
query  and  the  server  are  described  using  boolean  expression.  The  search  method 
is  based  on  the  similarity  measure  between  the  two  boolean  expressions. 
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7  Conclusion 


The  Internet  is  an  open  system  where  heterogeneous  agents  can  appear  and 
disappear  dynamically.  As  the  number  of  agents  on  the  Internet  increases, 
there  is  a  need  to  define  middle  agents  to  help  agents  locate  others  that  provide 
requested  services.  In  prior  research,  we  have  identified  a  variety  of  middle  agent 
types,  their  protocols  and  their  performance  characteristics.  Matchmaking  is  the 
process  that  brings  requester  and  service  provider  agents  together.  A  provider 
agent  advertises  its  know-how,  or  capability  to  a  middle  agent  that  stores  the 
advertisements.  An  agent  that  desires  a  particular  service  sends  a  middle  agent 
a  service  request  that  is  subsequently  matched  with  the  middle  agent’s  stored 
advertisements.  The  middle  agent  communicates  the  results  to  the  requester 
(the  way  this  happens  depends  on  the  type  of  middle  agent  involved).  We 
have  also  defined  protocols  that  allow  more  than  one  middle  agent  to  maintain 
consistency  of  their  adevertisement  databases.  Since  matchmaking  is  usually 
done  dynamically  and  over  large  networks,  it  must  be  efficient.  There  is  an 
obvious  trade-off  between  the  quality  and  efficiency  of  service  matching  in  the 
Internet. 

We  have  defined  and  implemented  a  language,  called  Larks,  for  agent  ad¬ 
vertisement  and  request  and  a  matchmaking  process  using  Larks.  Larks  ju¬ 
diciously  balances  language  expressivity  and  efficiency  in  matching.  Larks 
performs  both  syntactic  and  semantic  matching,  and  in  addition  allows  the 
specification  of  concepts  (local  ontologies)  via  ITL,  a  concept  language. 

The  matching  process  uses  five  filters,  namely  context  matching,  compari¬ 
son  of  profiles,  similarity  matching,  signature  matching  and  semantic  matching. 
Different  degrees  of  partial  matching  can  result  from  utilizing  different  combi¬ 
nations  of  these  filters.  Selection  of  filters  to  apply  is  under  the  control  of  the 
user  (or  the  requester  agent). 
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A  Syntax  of  Larks 

Definition  A.l:  Syntax  of  Larks 

The  syntax  of  Larks  is  given  by  the  following  production  system  in  EBNF-grammar: 


<  specification  > 

<  C Declaration  > 

<  CDec  > 

<  TDeclarations  > 

<  Delarations  > 


<  I  dent  >  [<  C  Declaration  >]  [<  TDeclarations  >] 
[<  Declarations  >]  [<  Constraints  >] 

Context*  <  CDec  > 

<  Ident  >'  *'  <  Termdefinition 

<  TDec  >  |  <  TDec  <  TDeclarations  > 

'input*  <  OptDecList  >  Output*  <  DecList  > 


<  TDec  > 

<  Dec  > 

<  DecList  > 

<  OptDecList  > 

<  OptDec  > 

<  TExp  > 

<  PType  > 

<  CTypie  > 


<  f?rp  > 

<  ExpjList  > 

<  aExp  > 

<  IdentList  > 

<  Constraints  > 

<  fomulaList  > 

<  formula  > 

<  atomList  > 

<  atom  > 

<  piredicate  > 

<  var  > 

<  const  > 


Type*  <  Ident  >  TExp  >]';*  |  'basicType*  <  IdentList  >' 

<  Ident  TExp  >  [,=,<  Exp  >]V 

<  _Dec  >  |  <  _Dec  >V  <  DecList  > 

<  OptDec  >  |  <  OptDec  <  OptDecList  > 

[^Optional/]  <  _Dec  > 

<  TV ar  >  |  <  BType  >  |  <  PType  >  |  <  CType  > 

Bool/  |  InE  |  Real/  |  String* 

,(,[<  Ident  >V]  <  TExp  [<  Ident  >V]  <  TExp  >')'  \ 

<  TExp  >  Y  <  TExp  >  | 

<  TExp  >  <  TExp  >  | 

'SetOf'  '('<  TExp  >')'| 

TistOf  ,(,Tf?rp,),| 

7{7<  ExpList  >,}/ 

<  aExp  >  |  Y<  ExpList  >')'  \  '{'<  ExpList  >,}/  I 

<  Exp  >'  (' <  ExpList  >')'  |  <  Exp  >'  <  Ident  > 

<  Exp  >  |  <  Exp  <  ExpList  > 

<  sConst  >  |  <  var  >  |  <  const  > 

<  Ident  >  |  <  Ident  <  IdentList  > 

[AnConstraints  <  formulaList  >] 

[,OutConstraints,  <  formulaList  >] 

<  formula  >  |  <  formula  <  formulaList  > 

<  atomList  > 

<  atom  >  |  <  atom  <  atomList  > 

<  predicate  >  |  Tot*  <  predicate  > 

<  Ident  > 

<  Ident  > 

<  Ident  > 


with  non-terminals  <  Ident  >,  <  var  >,  and  <  const  >  denoting  an  identifier, 
variable  and  constant,  respectively.  The  non-terminal  <  Termdefinition  >  refers 
to  that  in  the  concept  language  Itl  (see  below),  thus  denoting  a  kind  of  a  so-called 
’escape  hatch’  from  Larks  to  Itl. 


Convention: 

In  a  capability  description  or  request  any  term  definition  will  be  replaced  by  the  name 
of  the  corresponding  concept  or  role  which  is  assumed  to  be  available  in  the  local 
knowledge  base. 
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B  The  concept  language  Itl 


Definition  B.l:  Syntax  of  Itl 


The  syntax  of  the  concept  language 
in  EBNF-grammar: 

<  Terminology  >  ::  = 

<  Termdefinition  >  ::  = 

<  C onceptde f  inition  >  ::  = 

<  Roledef inition  >  ::  = 

<  Concept  >  ::  = 

<  Cone  >  :: 


<  AttrConc  > 

<  Role  > 

<  atomicC oncept  > 

<  atomicRole  > 

<  primComponent  > 

<  primConcComponent  > 

<  primRoleComponent  > 

<  aval  > 

<  Term  > 

<  ObjectSet  > 

<  Instance  > 

<  Concept  In  stance  > 

<  Rolelnstance  > 

<  NumRestr  > 

<  Object  > 


Itl  is  given  by  the  following  production  system 

<  Termde f  inition  >  + 

<  C onceptde  f  inition  >  |  <  Rolede  f  inition  > 

<  atomicC  oncept  >  '  =’  <  Concept  >  | 

<  atomicC  oncept  >  '  =’  <  Concept  > 

<  atomicRole  >  '  =’  <  .Role  >  | 

<  atomicRole  >  '  =’  <  Role  > 

<  Cone  >  |  <  AttrConc  > 

=  <  atomicC  oncept  >  | 

<  primComponent  >  |  '(not'  <  primConcComponent  >)  | 
'(and'  <  Concept  >+  ')'  | 

'(atleast'  n  <  Role  >')'  | 

'(atmost'  to  <  Role  >')'  | 

'(exists'  <  Role  >  <  Concept  >')'  | 

'(all'  <  Role  ><  Concept  >')'  | 

'(le'  <  num  >')'  |  '(ge'  <  num  >')'  | 

'(it'  <  num  >')'  |  '(gt'  <  num  >')' 

=  'aset('<  oral  >+  ')' 

=  '(androle'  <  Role  >+  ')'  | 

<  atomicRole  >  |  <  primRoleComponent  > 

=  <  identifier  >  |  'nothing' 

=  <  identifier  > 

=  <  primConcComponent  >  |  <  primRoleComponent  > 

=  <  identifier 

=  <  identifier 

=  <  identifier  > 

=  <  Concept  >  |  <  Role  > 

=  <  Instance  >* 

=  <  Concept  In  stance  >  |  <  Rolelnstance  > 

=  '('<  Object  >  <  atomicC  oncept  >')'  | 

'(<  Object  >  not'  <  primConcComponent  >')' 

=  '('<  Object  >  <  atomicRole  >  <  Object  >')'  | 

'('<  Object  >  <  NumRestr  >  <  atomicRole  >')' 

=  'atleast'  <  num  >  |  'atmost'  <  num  > 

=  <  identifier  > 


The  meaning  of  (atomic)  concept  or  role,  attribute  concept,  concept  and  role 
definition,  term  definition,  term,  terminology  and  object  set  is  defined  as  the  set  of 
strings  which  can  be  reduced  to  the  respective  non-terminal  symbols  in  the  production 
system. 

It  is  assumed  that  in  every  terminology  T  (written  in  Itl)  all  used  atomic  concepts 
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and  roles  are  unique  identifiers  and  defined  in  T ;  the  enumerable  sets  of  identifiers  for 
concepts  and  roles,  attribute  values  and  objects,  as  well  as  primitive  concept  and  role 
components  are  assumed  to  be  pairwise  disjoint.  In  addition,  every  primitive  compo¬ 
nent  (undefined  identifier)  in  a  terminology  is  assigned  a  given,  fixed  meaning6 . 


Definition  B.2:  Semantic  of  Itl 

Let  G  be  a  grammar,  V  interpretation  domain  and  D,  Da  disjoint  subsets  with 
V  =  D  l+J  Da.  V(S)  denotes  the  power  set  of  any  set  S.  The  semantic  of  Itl 
terms  is  defined  by  the  following  interpretation  function. 

f  Cone  ->■  V(V) 

e  :  \  Role  -e  V(D  x  V)  (1) 

[  Attr  — >■  Da 

e  is  a  iTL-interpretation  if  it  satisfies  the  following  equations: 


n 


e(and  Ci...C„)) 

=  r>«*) 

i  —  1 

(2) 

e((all  R  C)) 

=  {dev-. 

rg(d,e(R))  C 

t(C)} 

(3) 

^((exists  R  C)) 

=  {dev-. 

rg(d,  e(R))  n< 

iC)  1 0} 

(4) 

e((atleast  n  R)) 

=  {dev  -. 

1  rg(d,e(R)) 

1  >  n} 

(5) 

e((atmost  n  R)) 

=  {dev-. 

1  rg(d,  e(R)) 

1  <  n} 

(6) 

e(aset(ai,  ...,  an)) 

=  {£(ai)>  •• 

■  i f(an) } 

(7) 

e((not  Cp)) 

=  D\e(Cp 

') 

(8) 

e((androle  Ri...Rn)) 

= 

_ i 

(9) 

e(nothing) 

% — i 

=  0 

(10) 

rg(d,e(R)) 

:=  {y  eV  : 

(d,y)  e  e(R)j 

(11) 

rg(d,  e(R))  denotes  the  set  of  role  fillers  of  instance  d  for  the  role  R. 

All  attributes  ai,...,an  of  the  concept  asetfai . an)  are  interpreted  as 

constants,  i.e. ,  for  some  Da  C  Attr  we  assign  e(a8)  =  a8-,i  E  {1,  ..n}.  The 
interpretation  of  the  operators  (le  n),  (ge  n),  (it  n),  and  (gt  n)  for  numerical 
comparison  denotes  the  set  of  real  numbers  x  E  D  with  x  <  n,  x  >  n,  x  <  n, 
and  x  >  n,  respectively. 


6Primitive  components  are  elements  of  a  minimal  common  vocabulary  used  by  each  agent 
provider/user  for  a  construction  of  their  local  domain-dependent  terminologies  (and  object 
sets). 
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